fix(acp,core,relay): publish agent profiles on kind:10100 and move channel-add policy to 10101 - #4994

We're running exactly the topology this PR targets — three headless buzz-acp agents under systemd on a self-hosted relay — and hit the gap it fixes: the agents were fully functional (presence 20001 online, replying in channels) but invisible to Desktop's relay-agent directory until we manually published kind:10100 events for them.

Two field notes from that workaround that seem relevant to the current diff:

1. Durable status:"online" goes stale. Our manually published 10100 profiles carry status:"online" forever — Desktop showed the agents online even with their services stopped. The diff also writes "status": "online" into the profile. Since liveness already has a correct home (20001 heartbeat + 180s TTL + offline on graceful shutdown), could the durable profile omit status entirely and let surfaces overlay live presence (the direction fix(desktop): report agent presence from the relay, not the profile default #4537 takes for Pulse)? Otherwise every crash leaves a lying directory entry that nothing ever corrects.

2. Profile republish gated on presence_enabled. The membership-change republish path sits inside config.presence_enabled. An operator running --no-presence presumably still wants the agent discoverable and mentionable — the directory entry is identity/config, not liveness. Decoupling them keeps --no-presence meaning "no liveness signal" rather than "invisible".

Happy to test this branch against our production setup (self-hosted relay + 3 systemd headless agents + Desktop clients) and report back — including the 10100→10101 policy migration path, since our relay currently holds both manual 10100 profiles and set-add-policy writes that would collide.

Went back through the current diff. One correction to my own comment above, then three notes.

Correcting myself on status

I suggested the durable profile omit status and let surfaces overlay live presence. That would break the desktop directory as it stands:

• agents_from_events fills in "status": "offline" when the field is absent — desktop/src-tauri/src/nostr_convert.rs:479.
• relayStatusToManagedStatus maps "offline" → "stopped" and everything else → "deployed" — desktop/src/features/channels/ui/useChannelAgentSessions.ts:48.

So omitting the field doesn't defer to presence, it pins every agent to "stopped". Writing "online" at startup is right, and under the desktop's own mapping the field reads as deployed, not live.

The staleness point survives in a smaller and more concrete form: nothing ever writes the field back. The shutdown path already republishes presence as offline behind a 2s timeout —

// Best-effort: set presence to offline before exiting.
if config.presence_enabled {
    match tokio::time::timeout(
        Duration::from_secs(2),
        publish_presence(&presence_publisher, &presence_keys, "offline"),
    )

— and a symmetric publish_agent_profile(…, status: "offline") in that same block would cover the ordinary systemctl stop/restart case, which is what our fleet actually does day to day. A hard crash would still leave a stale entry; that one genuinely needs live presence overlaid at the surface, and that belongs outside this PR.

Relays older than this PR log the new profile at error level

Worth knowing for self-hosted deployments, which upgrade the relay and the agents separately.

On current main the 10100 side effect requires channel_add_policy and returns Err without it. Side effects run after the insert, and the error is logged rather than surfaced (crates/buzz-relay/src/handlers/ingest.rs:2955):

// error!, not warn!: the event was accepted but its side effects
// (channel creation, git repo seeding, …) did not run …
// Production runs RUST_LOG=error, so warn! made these failures invisible …
error!(event_id = %event_id_hex, kind = kind_u32, "Side effect failed: {e}");

So an agent built from this branch, pointed at a relay that isn't, still publishes a perfectly good profile — the event is stored, and Desktop and mobile read it fine. The only consequence is one error! line per publish, plus one per membership-change republish:

Side effect failed: kind:10100 missing channel_add_policy field

Not a blocker and not something this PR can fix on the relay side — the affected relays are already released. But since RUST_LOG=error is the production level precisely so these lines are visible, it's worth a sentence in the PR description saying relays should be updated before agents.

The merge conflict is one import block

git merge-tree upstream/main <this branch> conflicts in exactly one file, crates/buzz-relay/src/handlers/ingest.rs, and only inside use buzz_core::kind::{…}. main added KIND_PRIVATE_MANAGED_AGENT while this branch added KIND_CHANNEL_ADD_POLICY; both sides then rustfmt-rewrapped the whole list, so the textual hunks overlap even though the change is additive. Keep both names and let cargo fmt rewrap. Everything else, including the 248 lines in crates/buzz-acp/src/lib.rs, auto-merges clean.

Still open from my earlier comment

The presence_enabled gate. It reads a bit stronger now that I've been through the consumers: this profile is the only thing that puts an agent in the relay directory, and agentAutocompleteEligibility.ts uses respond_to/respond_to_allowlist from it to decide @-mention eligibility. So --no-presence currently means "invisible and un-mentionable", not "no liveness signal". Decoupling the profile publish from the flag is a one-line change if you agree with the reading.

Happy to run the buzz-acp half against our fleet — three headless agents under systemd on a self-hosted relay — once the conflict is off the branch. That deployment is itself the mixed-version case from the second note, since the relay predates 10101, so I can confirm both the directory result and the log behaviour empirically.